Praktikum AA1 „Reibwertbestimmung“

Versuchsaufbau

Verwendete Hardware

Am 16-bit-A/D-Wandler „IOtech AD488“ mit GPIB-Schnittstelle liegen die Analogsignale für Leistung, Drehmoment und Drehzahl an. Für die „kompensierten“ Ausgangswerte liegt der Erfassungsbereich bei ±30000, nicht ±32767, für ±10 V Eingangsspannung.

Kanal-zu-Messwert-Zuordnung
KanalSymbol1 V =10 V =AuflösungKommastellenHerkunftKommentar
C1P5/3 = 1,66 kW16,6 kW0,5 W3Messwellenicht ausgewertet
C2nm1000 U/min10000 U/min0,33 U/min0MesswelleNur positiv!
C3M0,25 Nm (unsicher)10 Nm0,01 Ncm3Messwelle
C4n400 U/min4000 U/min0Umrichterwacklig mit 1 Hz bei eingeschaltetem Motor
C5M2??3Umrichterungenutzt um bei 4 Kanälen zu bleiben

Dieses altertümliche Gerät verwendet kein SCPI. Aber das macht dessen Programmierung keineswegs schwieriger; die Steuerkommandos sind sogar etwas kürzer. Eine handliche Kurzübersicht ist als Faltblatt dabei.

Die beiden Datenerfassungsgeräte für Drehmoment (beide) und Drehzahl (nur oben)

Die Daten werden mittels permanenter binärer Messwertausgabe („T0G10“) ausgespuckt. „Kompensiert“ sind die „richtigen“ Messwerte. Die maximale Datenrate liegt dann bei 1 kSa/s. Das IOtech-Gerät kann anscheinend nicht schneller rechnen. „Unkompensiert“ („T0G11“) bedeutet, dass Offset- und Verstärkungskorrektur mit einem extra Kommando vom Gerät gelesen werden muss (dort vmtl. im EEPROM gespeichert). Nach der kanalweisen Verrechnung der „unkompensierten“ Daten kommt dasselbe heraus. Die maximale Datenrate erreicht dann (nur nur dann) den angegebenen Datenblattwert von 20 kSa/s für 4 Kanäle. LabVIEW hat Probleme mit dieser hohe Rate, wenn parallel Datenverarbeitung läuft, dies äußert sich in gelegentlichen Aussetzern bei der Erfassung. Mit 2 kSa/s läuft das Programm hinreichend stabil.

Von der Messwelle kommen leider nur positive Drehzahlen und damit Spannungen. Murks! Das Drehmomentsignal nutzt beide Richtungen.

Reinfall LabVIEW

Die Messdaten-Erfassung läuft in einer separaten While-Schleife ab. Die Daten wandern als Signalschnipsel in eine Queue. Sonst nichts. Diese Schleife bekommt laut LabVIEW-Dokumentation einen eigenen Thread: Ein typischer Worker-Thread. Er blockiert beim GPIB-Lesen auf den jeweils nächsten Datenblock. Die Leseroutine liest genau so viele Bytes ein wie für 100 ms Sampledaten erforderlich.
TODO: Er müsste jetzt bloß noch hochpriorisiert werden.

Alles weitere geschieht in einer weiteren While-Schleife: Sowohl die Weiterverarbeitung der Signalstückchen aus der Queue zur Darstellung in einer Art Oszilloskop als auch die gesamte Ereignisbehandlung. Ein typischer GUI-Thread. Er blockiert mit Timeout oder Benutzereingaben. Damit die Queue nicht überlaufen kann, wird diese im Timeout-Case der Ereignisbehandlung stets komplett geleert. Die herausfallenden Waveform-Schnipsel im 2D-Array werden — aneinandergereiht gedacht, nicht zwingend getan — weiterverarbeitet.

Hier ist die LabVIEW-Quelle für LabVIEW 2017 oder höher.

Elektro-Archäologie

Vorgefundenes Analogkabel zwischen Vibro-Meter und ADC488
SubD25♂AderSubD25♀Bedeutung
3rt1Leistung+
4or15Drehzahl+
6ge4Drehmoment+
13+25gn5Drehmoment-
br16Drehzahl-
sw2Leistung-
GehäuseSchirm-Schirm

Wie der Massebezug hergestellt wird ist unklar!! Vielleicht kommt deshalb so viel Rauschen raus.

(Feststellung: Nein, das ist nicht der Fall.)

Der 25-polige SubD-Stecker ist recht interessant belegt:

Anschlussbelegung des analogen Eingangs des AD488

Die Farben dienen der Visualisierung des bevorzugten symmetrischen Kabelanschlusses. Die Massen sind untereinander im Gerät verbunden, nicht jedoch mit Schutzerde.
Für die Verwendung eines Hosenträgerkabels via Schneidklemm-Adapter ist diese Anschlussweise eher suboptimal zu nennen, da die differenziellen Leitungen nicht nebeneinander liegen und untereinander nicht mit Masse getrennt sind. Das Pin 13 ist frei.

Tipp: Egal ob analoge oder digitale differenzielle Signale: Ethernetkabel sind dafür optimal — und preiswert zugleich. Bei analogen Kabeln eher CAT6 (paarweise geschirmt), bei digital genügt CAT5E (weniger Erdkapazität).

Anschluss CT-Umrichter

Für den Versuch machen sich neue Anschlüsse erforderlich. Lukrativ erscheint die Möglichkeit, Drehzahlistwerte digital abzufragen. Leider bekommt man diese nicht ohne Zeitversatz zum Drehmomentsignal. Auch kann man so vielleicht eine Solldrehzahl setzen und Reglerparameter beeinflussen.

Analog

Verwendete Anschlüsse
SchraubklemmeBedeutungAderSubD25♀AD488-Kanal
9Drehzahl, ±5 Vws18C4+
10Drehmoment, ±5 Vbr7C5+
11Bezugspotenzial, 0Vgn,ge19,8C4–,C5–
Schirm17

Da die Analogwerte schwanken, wird die Mittelwertbildung mit einem einstellbaren Zeitfenster realisiert. Um nicht jedesmal alle Abtastwerte durchrechnen zu müssen, wird jedes Signalschnipsel mit nützlichen Statistikwerten (Attribut „stat“) versehen:

Schade dass LabVIEW das nicht gleich selber tut. Was denen für die automatische Skalierung hilft. (Leere Signalschnipsel sollten keine Statistikwerte aufweisen.) Auch wenn mehrere Signalschnipsel verkettet werden, lässt sich daraus einfach berechnen:

Die Erkennung von ans Limit kommenden Messwerten und Ersatz durch ±INF wurde erst mal nicht eingebaut. Die Daten-Entschachtelung und Konvertierung zu Double erfolgt im Worker-Thread. (Möglicherweise keine gute Idee.)

RS-485

Dieser Anschluss des Umrichters ist auf RJ-45 (8P8C) herausgeführt: Sieht aus wie eine Ethernet-Buchse. Zur Adaptierung mit einem NI USB-485 wurde folgender Adapter erstellt:

Adapter; siehe Unidrive SP User Guide Seite 82
SignalNI USB-485CT-UmrichterAderfarbeChina-Konverter
SubD9♀RJ-45♂ISDN-FlachkabelSchraubklemme
GND13orange-
CTS+ — RTS+2,3-
RxD+ — TxD+4,82rotD+ oder A
RxD- — TxD-5,97braunD– oder B
CTS- — RTS-6,7-

Es werden tatsächlich nur diese 3 Adern benötigt. Damit das Anschlusskabel „unsichtbar“ hinter der Frontblende verschwinden kann, wurde dafür ein altes, flaches ISDN-Kabel zerschnitten. Ein Ethernetkabel wäre zu dick dafür.

Es muss nicht der 200 Euro teure NI-Adapter sein, dieser Konverter aus China für ein Hundertstel des Preises tut es auch.

Das Datenprotokoll ist Modbus-RTU. (Nix mit *IDN?! Das ist SCPI, üblich für GPIB.) Um den Drehzahlistwert an der Adresse 0.10 zu lesen ist folgendes zu senden:

Variable(n) abfragen; hier: Drehzahl
Sendedaten
OffsetWertBitsBedeutungAnordnung
018Slave-Adresse
138Wert(e) abfragen
208Adresse High-TeilMSBfirst
398Adresse Low-Teil -1
4116Anzahl aufeinanderfolgender SpeicherstellenMSBfirst
60x085416Modbus-CRCLSBfirst
Empfangsdaten
OffsetWertBitsBedeutungAnordnung
018Slave-Adresse
138Wert(e) abfragen
228Anzahl Bytes der Antwortdaten
3016DrehzahlMSBfirst
50x44B816Modbus-CRCLSBfirst

Das VI Modbus-RW.vi kümmert sich um das Anhängen, Abschneiden und Überprüfen der CRC. Es bekommt einen String am Eingang, der am besten mit der Funktion „Daten serialisieren“ erstellt wird. Umgekehrt wird der Antwortstring am besten mit „Daten deserialisieren“ auseinandergenommen. Um die Angaben für die immer konstante Slave-Adresse muss sich die nächste Software-Schicht kümmern.

LabVIEW-Kode: CRC-Berechnung für Modbus
LabVIEW-Kode: Schreiben und Antwort lesen, zweimal dieselbe CRC-Berechnung

Zum Setzen von Werten gibt es verschiedene Modbus-Telegramme. Am naheliegendsten ist der zum Setzen mehrerer audeinanderfolgender Adressen (16). Dies passt logisch zum oben verwendeten Telegrammformat (3). Eine Solldrehzahl lässt sich anscheinend nicht setzen, daher hier im Beispiel das Setzen von Parametern des PID-Drehzahlreglers:

Variable(n) setzen; hier: Proportionalteil kp des PID-Reglers
Sendedaten
OffsetWertBitsBedeutungAnordnung
018Slave-Adresse
1168Wert(e) setzen
208Adresse High-TeilMSBfirst
368Adresse Low-Teil -1
4116Anzahl aufeinanderfolgender SpeicherstellenMSBfirst
628Anzahl Bytes (2× die Zahl vom Offset 4)
75516kp = 0,0055MSBfirst
9????16Modbus-CRCLSBfirst
Empfangsdaten
OffsetWertBitsBedeutungAnordnung
018Slave-Adresse
1168Wert(e) setzen
208Adresse High-TeilMSBfirst
368Adresse Low-Teil -1
4????16Modbus-CRCLSBfirst
LabVIEW-Kode: Modbus-Wertabfrage für Umrichter